home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-houttuin-mailservers-01.txt < prev    next >
Text File  |  1993-03-21  |  39KB  |  1,136 lines
  1.  
  2.  INTERNET-DRAFT                                        Jeroen Houttuin
  3.  RARE WG-MSG                                          RARE Secretariat
  4.  rev. 2.1                                                   March 1993
  5.                                     
  6.                                     
  7.                  Recommendations for Mail Based Servers
  8.  
  9.  
  10. Abstract
  11.    
  12.    This document defines recommendations to be implemented in mail based
  13.    servers in the Internet e-mail community. The requirements only
  14.    affect the basic behaviour of servers, i.e. it mainly deals with how
  15.    header fields are handled. Although there is also a clear need for
  16.    recommendations in the field of end user requirements, such as
  17.    command syntaxes for archive servers, automatic distribution list
  18.    subscription, etc., such issues are considered more suitable to be
  19.    dealt with in a separate document.
  20.    
  21.    It is highly desirable that other e-mail networks connected to the
  22.    Internet, such as the GO-MHS community, also implement these
  23.    recommendations.
  24.  
  25. Discussion group
  26.    
  27.    This document is being discussed in the RARE Working Group on Mail
  28.    and Messaging (WG-MSG) and in the IFIP Mail Management Group. Please
  29.    send any comments to wg-msg@rare.nl or to houttuin@rare.nl .
  30.  
  31. Status of this Memo
  32.    
  33.    To do: more comprehensive explanations for the individual
  34.    recommendations. Finish the explicit parallel descriptions in both
  35.    RFC and X.400 terminology.
  36.    
  37.    This document is an Internet Draft. Internet Drafts are working
  38.    documents of the Internet Engineering Task Force (IETF), its Areas,
  39.    and its Working Groups. Note that other groups may also  distribute
  40.    working documents as Internet Drafts.
  41.    
  42.    Internet Drafts are draft documents valid for a maximum of six
  43.    months. Internet Drafts may be updated, replaced, or obsoleted by
  44.    other documents at any time.  It is not appropriate to use Internet
  45.    Drafts as reference material or to cite them other than as a "working
  46.    draft" or "work in progress."
  47.    
  48.    Please check the I-D abstract listing contained in each Internet
  49.    Draft directory to learn the current status of this or any other
  50.    Internet Draft.
  51.    
  52.    Distribution of this memo is unlimited.
  53.  
  54. Internet-Draft             MBS recommendations               March 1993
  55.  
  56.  
  57. Contents
  58.  
  59.    1. Introduction                                                  1
  60.    2. Definitions                                                   3
  61.    3. Mail based server types                                       5
  62.         3.1. Repliers                                               5
  63.         3.2. Forwarders                                             6
  64.    4. Recommendations                                               7
  65.         4.1. Attribute/header restrictions (AR)                     9
  66.         4.2. Attribute/header values (AV)                          10
  67.         4.3. Attribute/header conservation (AC)                    13
  68.         4.4. Addresses (AD)                                        13
  69.         4.5. Body (B)                                              14
  70.         4.6. Exceptions (E)                                        15
  71.         4.7. Implementation options (I)                            16
  72.    5. Implementations                                              17
  73.    6. Acknowledgements                                             17
  74.    7. Bibliography                                                 17
  75.    8. Abbreviations                                                18
  76.    9. Author's Address                                             19
  77.  
  78.  
  79. 1. Introduction
  80.  
  81.  
  82.  
  83. Mail Based Servers
  84.    
  85.    Electronic mail systems are increasingly being used as a basis for so
  86.    called Mail Based Servers (MBSs), such as echo servers, distribution
  87.    lists, etc. MBSs are used for a number of purposes:
  88.      
  89.      - Enhancing the Message Handling Environment. Examples of such
  90.        usage are distribution lists (DLs), for group communication, and
  91.        e-mail servers, for file and information retrieval.
  92.      
  93.      - Monitoring the status of the MHS. Examples of this usage are
  94.        echo servers and forced (non-)delivery messages (E.g. the so-
  95.        called nosuchuser test).
  96.    
  97.    Since MBSs deal with automatically receiving, forwarding and replying
  98.    to messages, which may themselves have been generated by automated
  99.    processes, strong requirements are needed on the one hand to minimise
  100.    human effort to manage such servers, and on the other hand to make
  101.    the behaviour of mail based servers deterministic enough to build
  102.    reliable tools upon them.
  103.    
  104.    A classic example of what can go wrong is when a mailing list
  105.    contains an invalid address. The remote mailer generates a non-
  106.    delivery message and sends it to the originator of the original
  107.  
  108.  
  109. Houttuin                   Expires September 1993             [page  1]
  110.  
  111. Internet-Draft             MBS recommendations               March 1993
  112.  
  113.  
  114.    message, which, under circumstances, could be the list itself, which
  115.    then again distributes the non-delivery message to the non-existing
  116.    recipient, etc. Following strict recommendations on how mailing lists
  117.    should handle message header fields can avoid such looping-endangered
  118.    situations.
  119.    
  120.    A more complicated example of the usefulness of strong requirements
  121.    for mail based servers is the following: suppose a distributed tool
  122.    will check the connectivity of mailers by sending a message to an
  123.    echo-server. The connectivity tool could request the echo to be sent
  124.    to a remote component of the tool instead of to itself. If for some
  125.    reason the address of that other component cannot be routed to, an
  126.    automatically generated non-delivery message could be sent back to
  127.    the echo server, which results in an echo loop.
  128.    
  129.    The recommendations defined in this document will as much as possible
  130.    be aligned with comparable rules that either have already been used
  131.    for a long time (X.400(84) Status Reports; distribution lists in the
  132.    Internet), or are already defined in other documents (X.400(88) DLs).
  133.  
  134.  
  135. Approach
  136.    
  137.    If all MBSs would agree to implement a common set of recommendations,
  138.    this set could be fairly small. In practice however, there are some
  139.    reasons why such a 'minimum approach' will not work:
  140.      
  141.      - The most obvious reason is that one cannot realistically expect
  142.        all networks and software developers to implement one common
  143.        strict set of rules. In different mail communities, different
  144.        MBS conventions have already been used for a long time. Some of
  145.        these conventions can be unacceptable for other communities to
  146.        implement.
  147.      
  148.      - MBSs can be build upon different underlying protocols. For
  149.        instance, it is almost impossible to have one small set of rules
  150.        that will prevent problems between any combination of MBSs, e.g.
  151.        between an RFC 822 MBS running over NJE and a P1 based MBS. More
  152.        problems can be expected because header fields are crucial for
  153.        the properly functioning of MBSs, and protocol gateways will not
  154.        always map header fields bijectively.
  155.      
  156.      - Not all MBSs are controlled by software developers or network
  157.        operators. Any user can write a simple program that will have
  158.        the functionality of an MBS.
  159.    
  160.    Because the 'minimum approach' is not feasible, this document
  161.    recommends the 'unilateral safety approach'. The idea is that any MBS
  162.    that implements the complete set of recommendations will be safe from
  163.    harm, regardless of what other 'dumb' MBSs it is interacting with.
  164.  
  165.  
  166. Houttuin                   Expires September 1993             [page  2]
  167.  
  168. Internet-Draft             MBS recommendations               March 1993
  169.  
  170.    
  171.    This results in quite a large number of recommendations; not every
  172.    single one of them is strictly necessary to prevent problems, but
  173.    none of them will 'hurt' the functioning of an MBS. As for the
  174.    programming overhead caused by this document, there is at least one
  175.    example of an echo server (Echoput) that implements the full set of
  176.    recommendations; the size of the (perl) code fits on two pages.
  177.    
  178.    In addition to the rules that should protect against loops and
  179.    explosions, there are also some recommendations reflecting common
  180.    sense. For instance, if a user sends a message flagged 'urgent' to a
  181.    mail based file server, he would not only expect his request message
  182.    to be handled with extra priority, but also the reply message.
  183.  
  184.  
  185. Protocols
  186.    
  187.    Depending on the implementation of the MBS, different recommendations
  188.    may be used. E.g. A P1 MBS cannot follow all recommendations for RFC
  189.    822 based MBSs and vice versa.
  190.    
  191.    For the reader's convenience, the requirements that are applicable to
  192.    different MBS implementations are explicitly stated in the different
  193.    terminologies. The requirements are labelled as follows:
  194.      
  195.      #RFC#     Applies to RFC 822 on top of RFC 821 (SMTP) based MBSs
  196.      #821#     Applies to RFC 821 (SMTP) based MBSs
  197.      #822#     Applies to RFC 822 based MBSs
  198.      #400#     Applies to X.400 (both 84 and 88) based MBSs
  199.      #84#      Applies to X.400(84) based MBSs
  200.      #88#      Applies to X.400(88) based MBSs
  201.      #P1#      Applies to P1 based MBSs
  202.      #P2#      Applies to P2 based MBSs
  203.      #P3#      Applies to P3 based MBSs
  204.  
  205.  
  206. 2. Definitions
  207.  
  208.  
  209.  
  210. Mail Based Server
  211.    
  212.    An MBS is a process that automatically generates one or more messages
  213.    (the output messages) as a result of receiving a message (the input
  214.    message). An MBS can be modelled and/or implemented in one of the
  215.    following ways:
  216.      
  217.      - #RFC#: As a process sitting directly on top of SMTP. This is
  218.        called an 821 MBS. If, in addition, the MBS is RFC 822 based, it
  219.        is called an 822 MBS.
  220.  
  221.  
  222.  
  223. Houttuin                   Expires September 1993             [page  3]
  224.  
  225. Internet-Draft             MBS recommendations               March 1993
  226.  
  227.  
  228.  
  229.      - #400#: within the MTS, in which case it can be considered an
  230.        enhancement of the X.400 message dispatcher. This is called a P1
  231.        MBS.
  232.      
  233.      - #400#: as an MTS service user, in which case it can be
  234.        considered an automated User Agent (UA). Per default, this is
  235.        called a P3 MBS. If, in addition, the MBS is P2 based, it is
  236.        called a P2 MBS. P7 based MBSs are not considered in this
  237.        document.
  238.    
  239.    The number of output messages and its contents depend on the kind of
  240.    server and on the contents of the input message.
  241.  
  242.  
  243. Dedicated and non-dedicated MBSs
  244.    
  245.    A dedicated MBS is an MBS that is meant to be used as an MBS only.
  246.    Examples of non-dedicated MBSs are temporarily auto-forwarding user
  247.    agents (UAs), and UAs that automatically send back vacation notes
  248.    (auto-repliers). Although software developers are encouraged to
  249.    implement such features as if it concerned a dedicated MBS, there are
  250.    some substantial differences between the two types, the main one
  251.    being that it is not realistic to assume a separate MBS administrator
  252.    (see below) for every stand-alone UA.
  253.  
  254.  
  255. MBS administrator
  256.    
  257.    For every dedicated MBS, there exists an MBS administrator who is
  258.    responsible for managing the MBS.
  259.  
  260.  
  261. Input- and output messages
  262.    
  263.    An input message is a message that triggers the generation of (a)
  264.    message(s) by an MBS.
  265.    
  266.    An output message is a message that is being generated by an MBS as a
  267.    result of a received input message.
  268.    
  269.    If an MBS encounters an exceptional situation (as defined in the
  270.    recommendations below), one exception output message is generated
  271.    instead of a regular output message. If a non-dedicated MBS does not
  272.    have an MBS administrator, the exception output message may either be
  273.    sent to the originator (see below) of the input message instead, or
  274.    no output message may be generated at all.
  275.  
  276.  
  277.  
  278.  
  279.  
  280. Houttuin                   Expires September 1993             [page  4]
  281.  
  282. Internet-Draft             MBS recommendations               March 1993
  283.  
  284.  
  285. MBS Submit Permission
  286.    
  287.    Associated with an MBS is a number of addresses that are allowed to
  288.    use the MBS (I.e. have the MBS send output messages). Implementation
  289.    of MBS Submit Permission is considered a local matter. The main
  290.    implementation options are:
  291.      
  292.      - Implicit: Only those addresses explicitly listed are not allowed
  293.        to send messages to the MBS.
  294.      
  295.      - Explicit: Only those addresses explicitly listed are allowed to
  296.        send messages to the MBS.
  297.  
  298.  
  299. Message originator
  300.    
  301.    #RFC# The originator of an input message is defined as the value of
  302.    the Sender: field, or if this attribute is not present, the value of
  303.    the From: field. For non RFC 822 messages, the originator of an input
  304.    message is defined as the value on the RFC 821 MAIL FROM: line.
  305.    
  306.    #400# For P2 messages, the originator of an input message is defined
  307.    as the P2.originator, or if this attribute is not present, the
  308.    P2.authorizingUsers. For non-P2 messages, the originator of an input
  309.    message is defined as the P1.originator.
  310.  
  311.  
  312. 3. Mail based server types
  313.  
  314.    
  315.    This chapter defines the different types of MBSs. Two main types are
  316.    identified: repliers and forwarders.
  317.  
  318.  
  319. 3.1. Repliers
  320.    
  321.    Intuitively speaking, a replier is an MBS that will send an output
  322.    message to the originator of the input message. There are also
  323.    exceptions to this rule, such as replying to a Reply-To: field. More
  324.    formally speaking, a replier is characterised by the fact that the
  325.    recipient of the output message is uniquely defined in (the heading
  326.    of) the input message. The different types of repliers can be
  327.    classified by the number and content of the output message.
  328.  
  329.  
  330. Echo server
  331.    
  332.    An echo server is a dedicated replier that will generate exactly one
  333.    output message, containing the input message.
  334.  
  335.  
  336.  
  337. Houttuin                   Expires September 1993               [page  5]
  338.  
  339. Internet-Draft             MBS recommendations                 March 1993
  340.  
  341.  
  342. Mailer demon
  343.    
  344.    This document does not consider the behaviour of X.400 delivery
  345.    reports and notifications, which is assumed to be well defined in
  346.    X.400 already.  RFC 822 mailers and RFC 1327 gateways however can
  347.    generate a message explaining the (NON-)Delivery of an input message.
  348.    In this case the mailer/gateway is acting as an MBS.
  349.    
  350.    For mailer demons, the MBS administrator is the administrator of the
  351.    mailer/gateway.
  352.  
  353.  
  354. Command server
  355.    
  356.    The contents of an output message submitted by a command server
  357.    depend on commands that were included in the input message. Concrete
  358.    examples are file servers, e-mail archie servers, DL-registration
  359.    servers and address conversion servers.
  360.    
  361.    Although it is beyond the scope of this document to define detailed
  362.    requirements for the command syntax used by command servers, some
  363.    general recommendations concerning header fields are made in this
  364.    document.
  365.  
  366.  
  367. Auto-replier
  368.    
  369.    Some UAs have an auto-reply feature that will temporarily and/or
  370.    conditionally turn the UA into an MBS. Thus an auto-replier is a non-
  371.    dedicated replier. The content of the output message is often a note
  372.    such as 'I am on holidays.' An auto-replier has a certain lifetime,
  373.    which is defined as the time span between switching the auto-replier
  374.    on and back off again.
  375.  
  376.  
  377. 3.2. Forwarders
  378.    
  379.    A forwarder is an MBS that will send its output messages to a list of
  380.    recipients. These recipients are independent of (the heading of) the
  381.    input message.
  382.  
  383.  
  384. Distribution List
  385.    
  386.    Upon receiving an input message, a DL will generate output messages
  387.    to a list of DL members, which is managed by the DL administrator.
  388.    
  389.    At the moment many vendor-specific implementations of DLs exist, some
  390.    of which are nothing more than local multi-recipient aliases, others
  391.    use local directories for DL expansion. This document defines the
  392.    requirements for DLs as well as implementation options.
  393.    
  394. Houttuin                   Expires September 1993             [page  6]
  395.  
  396. Internet-Draft             MBS recommendations               March 1993
  397.  
  398.  
  399.    A moderated DL is modelled as a normal DL with an extra filtering of
  400.    the input messages by a human. In case of message rejection by the
  401.    moderator, it is considered good manners for the moderator to follow
  402.    the recommendations that this document describes for mailer demons.
  403.    If the message is accepted for distribution, the moderator will
  404.    transparently pass through all MBS control information (headers) to
  405.    the actual DL. The moderation process itself is considered a local
  406.    matter.
  407.  
  408.  
  409. Auto-forwarder
  410.    
  411.    Some UAs have an auto-forward feature that will temporarily and/or
  412.    conditionally turn the UA into an MBS. Thus an auto-forwarder can be
  413.    considered a non-dedicated forwarder. Upon receiving an input
  414.    message, an auto-forwarder will submit an output message to a locally
  415.    defined (list of) address(es), which is managed by the owner of the
  416.    UA. Although an auto-forwarder often has a certain lifetime, like an
  417.    auto-replier, this has no implications for the requirements for auto-
  418.    forwarders.
  419.  
  420.  
  421. 4. Recommendations
  422.  
  423.    
  424.    Depending on the implementation, MBSs follow the requirements defined
  425.    in RFC 822, RFC 821, X.411 and/or X.420 as a minimum.
  426.    
  427.    This document describes additional requirements in terms of RFC 821,
  428.    RFC 822, P1, P3, and P2. Note that some RFC 822 recommendations deal
  429.    with non-standard headers described in RFC 1327. This is needed to
  430.    provide protection across gateways.
  431.    
  432.    The following table lists the recommendations for the MBS types
  433.    distinguished above. The key to the symbols is self-explanatory. The
  434.    last column states, for each recommendation, which MBS
  435.    implementations are affected.
  436.                                           
  437.    
  438.    
  439.  
  440.  
  441.                                       Key to symbols in table 1
  442.                                           +     Recommended
  443.                                           s      Suggested
  444.                                           o     Optional
  445.                                           d     Don't care
  446.                                           n/a   Not applicable
  447.                                           .     Depends on other
  448.                                           factors
  449.                                           -     Not recommended
  450.  
  451. Houttuin                   Expires September 1993             [page  7]
  452.  
  453. Internet-Draft             MBS recommendations               March 1993
  454.  
  455.            auto-  comm.  mail.   echo   auto-  dist.    protocols
  456.            answ.  serv.  demon   serv.  forw.  list
  457.  
  458.     AR1.1     +      +      +      +      .      .      P2
  459.     AR1.2     +      +      +      +      .      .      822 P2
  460.     AR1.3     +      +      +      +      .      .      822 P2
  461.     AR1.4     +      +      +      +      .      .      88.P1 88.P3
  462.     AR1.5     +      d      +      d      d      .      822 P2
  463.     AR2       +      +      +      +      +      .      all
  464.     AR3       o      +      -      +      n/a    n/a    822 P2
  465.     AR4       o      +      -      +      n/a    n/a    822 P2
  466.     AR5       o      +      .      +      n/a    n/a    822 P2
  467.     AV1       o      +      -      +      .      .      822 P2
  468.     AV2       s      +      +      +      .      .      all
  469.     AV3       +      +      +      +      n/a    n/a    822 P2
  470.     AV4       +      +      +      +      n/a    n/a    822 P2
  471.     AV5       o      +      +      +      .      .      821 P1 P3
  472.     AV6       o      +      +      +      .      .      822 P2
  473.     AV7       +      +      +      +      .      .      P1 P3
  474.     AV8       +      +      +      +      .      .      P2
  475.     AV9       s      s      o      +      -      -      822 P2
  476.     AV10      -      -      -      -      s      -      822 P2
  477.     AV11      .      .      +      .      n/a    n/a    821 P1 P3
  478.     AV12      .      .      +      .      n/a    n/a    822 P2
  479.     AV13      +      +      +      +      +      +      P1
  480.     AV14      -      -      -      -      +      -      822 P2
  481.     AC1       +      +      +      +      +      +      822 P2
  482.     AC2       +      +      +      +      +      +      822 P2
  483.     AC3       +      +      +      +      +      +      822 P1 P3
  484.     AC4       .      .      .      s      +      +      P1 P3
  485.     AC5       -      -      -      -      -      +      P1 P3
  486.     AD1       +      +      +      +      +      +      all
  487.     AD2       o      -      +      -      o      -      all
  488.     AD3       n/a    n/a    n/a    +      n/a    n/a    all
  489.     AD4       n/a    s      n/a    s      n/a    n/a    all
  490.     AD5       n/a    n/a    +      n/a    n/a    n/a    all
  491.     AD6       n/a    n/a    n/a    n/a    n/a    s      all
  492.     B1        -      o      s      +      -      -      822 P2
  493.     B2        o      o      o      o      -      o      822 P2
  494.     B3        n/a    +      n/a    n/a    n/a    n/a    822 P2
  495.     B4        n/a    +      n/a    n/a    n/a    n/a    822 P2
  496.     B5        -      -      -      -      +      -      P2
  497.     E1        +      +      +      +      +      +      822 P2
  498.     E2        +      +      +      +      +      +      all
  499.     I1        n/a    s      n/a    s      n/a    s      all
  500.     I2        o      +      +      +      o      o      all
  501.     I3        s      n/a    n/a    n/a    n/a    n/a    all
  502.     I4        n/a    n/a    n/a    n/a    n/a    s      n/a
  503.  
  504.                     Table 1. Table of recommendations
  505.  
  506.  
  507.  
  508. Houttuin                   Expires September 1993             [page  8]
  509.  
  510. Internet-Draft             MBS recommendations               March 1993
  511.  
  512.  
  513. 4.1. Attribute/header restrictions (AR)
  514.    
  515.    AR1
  516.         
  517.         The following attributes will not be used in the output message:
  518.    
  519.    AR1.1
  520.         
  521.         #P2# Recipient.replyRequest (i.e. should equal FALSE, as per
  522.         default)
  523.    
  524.    AR1.2
  525.         
  526.         #84#P2#        replyBy
  527.         #88#P2#        reply-time
  528.         #822#          Reply-By:
  529.    
  530.    AR1.3
  531.         
  532.         #84#P2#        expiryDate
  533.         #88#P2#        expiry-time
  534.         #822#          Expiry-Date:
  535.    
  536.    AR1.4
  537.         
  538.         #88#P1#P3#     Proof-of-delivery-request
  539.         
  540.         the value of this argument defaults to proof-of-delivery-not-
  541.         requested.
  542.    
  543.    AR1.5
  544.         
  545.         #84#P2# replyToUsers
  546.         #88#P2# reply-recipients
  547.         #822# Reply-To:
  548.    
  549.    AR2
  550.         
  551.         An auto-forwarded message is not valid as an input message. The
  552.         result is the generation of an exception output message.
  553.    
  554.    AR3
  555.         
  556.         If the following field is present in the input message, the
  557.         output message will be sent to this address. Otherwise the
  558.         output message will be sent to the originator of the input
  559.         message. If the following field contains more than one address,
  560.         an output message is at least sent to the first address of this
  561.         filed. Sending to the others is not recommended.
  562.         
  563.  
  564.  
  565. Houttuin                   Expires September 1993             [page  9]
  566.  
  567. Internet-Draft             MBS recommendations               March 1993
  568.  
  569.  
  570.         #84#P2# replyToUsers
  571.         #88#P2# reply-recipients
  572.         #822# Reply-To:
  573.    
  574.    AR4
  575.         
  576.         #822# If an output message is not sent to the originator of the
  577.         input message, its From: field field will contain the addresses
  578.         of the From: and the Sender: fields of the input message. In
  579.         this case the Sender: field of the output message contains the
  580.         address of the MBS administrator.
  581.         
  582.         #P2# If an output message is not sent to the P2.originator of
  583.         the input message, its P2.authorizingUsers field will contain
  584.         the addresses of the P2.originator and the P2.authorizingUsers
  585.         of the input message.
  586.    
  587.    AR5
  588.         
  589.         Echo servers will send an exception output message if the input
  590.         message contains either of the following attributes:
  591.         
  592.         #822# In-Reply-To:
  593.                     References:
  594.         
  595.         #P2#  In-Reply-To
  596.                     crossReferences
  597.  
  598.  
  599. 4.2. Attribute/header values (AV)
  600.    
  601.    AV1
  602.         
  603.         If the following field is used in the output message, it will
  604.         not contain the address of the MBS.
  605.         
  606.         #84#P2# replyToUsers
  607.         #88#P2# reply-recipients
  608.         #822# Reply-To:
  609.    
  610.    AV2
  611.         
  612.         Repliers will not send output messages to addresses which are
  613.         likely to be MBSs, such as addresses with the following values
  614.         in the local address designator (S, CN, localpart):
  615.          
  616.          autoanswer
  617.          echo
  618.          listserv
  619.          mailerdaemon
  620.  
  621.  
  622. Houttuin                   Expires September 1993             [page 10]
  623.  
  624. Internet-Draft             MBS recommendations               March 1993
  625.  
  626.  
  627.          mirror
  628.          netserv
  629.          server
  630.         
  631.         These values must be matched in any combination of upper case
  632.         and lower case. Instead, an exception output message is
  633.         generated. This list is subject to change; an up-to-date version
  634.         of this list is available in [Noreply]
  635.    
  636.    AV3
  637.         
  638.         The following attribute of the output message will have the
  639.         following value
  640.         
  641.         #84#P2# inReplyTo : IPMessageID of input message
  642.         #88#P2# replied-to-IPM : this-IPM of input message
  643.         #822# In-Reply-To: : Message-ID of input message
  644.    
  645.    AV4
  646.         
  647.         The following attributes are optional in an output message. If
  648.         used, they will contain the following value
  649.         
  650.         #84#P2# crossReferences : IPMessageID of input message
  651.         #88#P2# related-IPMs : this-IPM of input message
  652.         #822# References: : Message-ID of input message
  653.    
  654.    AV5
  655.         
  656.         #P1#P3# The P1.originator of the output message contains the
  657.         address of the MBS administrator.
  658.         
  659.         #821# The MAIL FROM: line of the output message contains the
  660.         address of the MBS administrator.
  661.    
  662.    AV6
  663.         
  664.         #P2# The P2.originator of the output message contains the
  665.         address of the MBS administrator.
  666.         
  667.         #822# The From: field of the output message contains the address
  668.         of the MBS administrator.
  669.    
  670.    AV7
  671.         
  672.         #84#P1#P3#  Every PerRececipientFlag in the output message will
  673.         have the following bits set:
  674.                 
  675.                 Report Request:           01
  676.                 User Report Request:00
  677.         
  678.  
  679. Houttuin                   Expires September 1993             [page 11]
  680.  
  681. Internet-Draft             MBS recommendations               March 1993
  682.  
  683.  
  684.         i.e. the Non-delivery Notification service will be prevented.
  685.    
  686.    AV8
  687.         
  688.         The following argument will be empty in the output message:
  689.         
  690.         #84#P2# Recipient.reportRequest
  691.         #88#P2# NotificationRequests
  692.    
  693.    AV9
  694.         
  695.         The following attribute of the output message will contain the
  696.         string 'Re: ', concatenated with the subject of the input
  697.         message.
  698.         
  699.         #822# Subject:
  700.         #P2# subject
  701.    
  702.    AV10
  703.         
  704.         The following attribute of the output message will contain the
  705.         subject of the input message, concatenated with the string
  706.         '(for)'.
  707.         
  708.         #822# Subject:
  709.         #P2# subject
  710.    
  711.    AV11
  712.         
  713.         #P1#P3# The P1.recipient of a (non-)DM equals the P1.originator
  714.         of the input message.
  715.         
  716.         #821# The RCPT TO: field of a (non-)DM equals the MAIL FROM: of
  717.         the input message.
  718.    
  719.    AV12
  720.         
  721.         #P2# The P2.recipient of a (non-)DM equals the P1.originator of
  722.         the input message.
  723.         
  724.         #822# The To: field of a (non-)DM equals the originator of the
  725.         input message.
  726.    
  727.    AV13
  728.         
  729.         #P1# All P1.ExtensionIdentifiers in an output message will be
  730.         distinct.
  731.    
  732.  
  733.  
  734.  
  735.  
  736. Houttuin                   Expires September 1993             [page 12]
  737.  
  738. Internet-Draft             MBS recommendations               March 1993
  739.  
  740.  
  741.    AV14
  742.         
  743.         #P2# The output message(s) will have the P2.autoForwarded flag
  744.         set to true.
  745.  
  746.  
  747. 4.3. Attribute/header conservation (AC)
  748.    
  749.    The following attributes will have the same value in the output
  750.    message as in the input message
  751.    
  752.    AC1
  753.         
  754.         In order to propagate the originator's request for privacy to
  755.         the output message(s):
  756.         
  757.         #822#          Sensitivity:
  758.         #P2#           P2.sensitivity
  759.    
  760.    AC2
  761.         
  762.         #822#          Importance:
  763.         #P2#           Importance
  764.    
  765.    AC3
  766.         #822#          Priority:
  767.         #P1#P3#        Priority
  768.    
  769.    AC4
  770.         
  771.         #84#P1#P3#     ContentType
  772.    
  773.    AC5
  774.         
  775.         #P1#P3#        contents
  776.  
  777.  
  778. 4.4. Addresses (AD)
  779.    
  780.    Please note that all recommendations for names of MBSs and MBS
  781.    administrators concern internationally used MBSs. Local MBSs can use
  782.    similar mechanisms in their local language.
  783.    
  784.    AD1
  785.         
  786.         The address of the MBS administrator will be the same as that of
  787.         the MBS, except for the
  788.         
  789.         #RFC# localpart
  790.         #400# Personal Name
  791.    
  792.  
  793. Houttuin                   Expires September 1993             [page 13]
  794.  
  795. Internet-Draft             MBS recommendations               March 1993
  796.  
  797.  
  798.    AD2
  799.         
  800.         The MBS administrator of a mailer demon has an address with the
  801.         following local address designation:
  802.    
  803.    AD3
  804.         
  805.         The following attribute of the echo server address will have the
  806.         value "echo".
  807.         
  808.         #RFC# localpart
  809.         #400# Personal Name
  810.    
  811.    AD4
  812.         
  813.         The following attribute in the address of the administrator of a
  814.         dedicated replier is that of the replier, concatenated with    "-
  815.         reply".
  816.         
  817.         #RFC# localpart
  818.         #400# Surname
  819.    
  820.    AD5
  821.         
  822.         A message addressed to an address with the following local
  823.         address designation will always result in an NRN or a non-DM
  824.         being generated.
  825.         
  826.         #RFC# localpart = nosuchuser
  827.         #84# Surname=nosuchuser
  828.         #88# Surname=nosuchuser ; CN=nosuchuser
  829.    
  830.    AD6
  831.         
  832.         The following attribute in the address of the administrator of a
  833.         dedicated replier is that of the replier, concatenated with    "-
  834.         request".
  835.         
  836.         #RFC# localpart
  837.         #400# Surname
  838.  
  839.  
  840. 4.5. Body (B)
  841.    
  842.    B1
  843.         
  844.         The complete input message (including headers) will be included
  845.         in the output message in a readable format, e.g. in IA5Text or
  846.         ASCII.
  847.    
  848.  
  849.  
  850. Houttuin                   Expires September 1993             [page 14]
  851.  
  852. Internet-Draft             MBS recommendations               March 1993
  853.  
  854.  
  855.    B2
  856.         
  857.         Additional information is included in separate bodyparts of the
  858.         output message.
  859.    
  860.    B3
  861.         
  862.         Commands will only be put in the body of the input message, e.g.
  863.         a command server will ignore the following field.
  864.         
  865.         #822#          Subject:
  866.         #P2#           subject
  867.    
  868.    B4
  869.         
  870.         The recipient of the output message can be uniquely identified
  871.         from the heading of the input message. I.e. Alternate recipients
  872.         will not be negotiated in the body of the input message. This
  873.         will ensure that the recipients can still be uniquely identified
  874.         after the input message has traversed a protocol gateway.
  875.    
  876.    B5
  877.         
  878.         #P2# The input message will be encoded as a
  879.         P2.ForwardedIPMessage bodypart in the output message.
  880.  
  881.  
  882. 4.6. Exceptions (E)
  883.    
  884.    E1
  885.         
  886.         In case of an MBS Submit Permission violation
  887.         
  888.         #822#P2#    a non delivery message will be sent to the
  889.         originator of the input message. The non delivery message will
  890.         have the following text in the message body:
  891.                 
  892.                 "Originator not allowed to send to this address"
  893.         
  894.         #84#P1# a P1.DeliveryReportMPDU will be sent to the
  895.         P1.originator of the input message. The P1.DeliveryReportMPDU
  896.         will have the following values:
  897.                 
  898.                 ReasonCode:               unableToTransfer(1)
  899.                 DiagnosticCode:           uaUnavailable(4)
  900.                 SupplementaryInformation: "Originator not allowed to
  901.                   send to this address"
  902.    
  903.  
  904.  
  905.  
  906.  
  907. Houttuin                   Expires September 1993             [page 15]
  908.  
  909. Internet-Draft             MBS recommendations               March 1993
  910.  
  911.  
  912.    E2
  913.         
  914.         Only the types of input messages listed below are valid as input
  915.         messages. Any other type of input message (reports, receipt
  916.         notifications) will lead to the generation of an exception
  917.         output message.
  918.         
  919.         #84#P1# UserMPDU
  920.         #84#P2# IM-UAPDU
  921.         #88#P1# Message
  922.         #88#P2# IPM
  923.         #822# No restrictions
  924.         
  925.         #400# P1.Probes are expected to be handled by the MTS and are
  926.         thus not interpreted by the MBS itself.
  927.  
  928.  
  929. 4.7. Implementation options (I)
  930.    
  931.    I1
  932.         
  933.         MBS Submit Permission implementation will be 'implicit'. This
  934.         means that MBSs that have not explicitly implemented this
  935.         function can still claim to be implicitly open to anyone.
  936.    
  937.    I2
  938.         
  939.         The MBS logs the originator of the input message and the
  940.         recipient(s) of the output message(s) so that the MBS
  941.         administrator can track down malicious behaviour. Any further
  942.         logging is optional.
  943.    
  944.    I3
  945.         
  946.         Auto-repliers will at least log the originator of the input
  947.         message. During the lifetime of an auto-replier, at most one
  948.         output message per input message originator is generated.
  949.    
  950.    I4
  951.         
  952.         #P2# Even if a DL is used for distribution of P2 messages, it is
  953.         still recommended to implement it within the MTS, i.e. as P1
  954.         MBSs. This has some important advantages over P3/P2 based
  955.         implementations (see also [SHK 92]):
  956.                 
  957.                 - Using P3 would result in loosing P1.TraceInformation
  958.                 - Better alignment with X.400(88), which also defines
  959.                   DLs within the MTS
  960.                 - An MTS DL distributes P1.UMPDUContent transparently,
  961.                   and will thus implicitly implement one of the
  962.                   requirements for DLs.
  963.  
  964. Houttuin                   Expires September 1993             [page 16]
  965.  
  966. Internet-Draft             MBS recommendations               March 1993
  967.  
  968.  
  969. 5. Implementations
  970.  
  971.    
  972.    There are a number of MBS implementations that follow most of the
  973.    recommendations listed in this document. They include:
  974.      
  975.      Echoput            (echo server)
  976.      AUSSIE             (echo server)
  977.      Concord            (echo server, DLs)
  978.      Squirrel           (command server)
  979.      EAN                (DLs, auto-forwarding, auto-answer, echo)
  980.      PP                 (DLs, auto-answer, echo)
  981.  
  982.  
  983. 6. Acknowledgements
  984.  
  985.    
  986.    Within the context of the connectivity testing tool 'concord',
  987.    initial work on the requirements for echo servers and distribution
  988.    lists was done within COSINE MHS and XNREN ([Concord]).
  989.    
  990.    Thanks for ideas, comments, flames and corrections: Allen Cargille
  991.    (XNREN), Harald Alvestrand (SINTEF), Urs Eppenberger (SWITCH), Paul
  992.    Klarenberg (NetConsult), Ignacio Martinez (redIRIS), Juan Pizzorno
  993.    (DFN), Eric Thomas (SUNET), Johan Vromans (Multihouse).
  994.  
  995.  
  996. 7. Bibliography
  997.  
  998.       
  999.       821         Jonathan B. Postel, "Simple Mail Transfer Protocol",
  1000.                   RFC 821, University of Southern California, August
  1001.                   1982
  1002.       
  1003.       822         Crocker, D., "Standard of the Format of ARPA Internet
  1004.                   Text Messages", RFC 822, UDEL, August 1982.
  1005.       
  1006.       1211        Westine, A. & Postel, J., "Problems with the
  1007.                   Maintenance of Large Mailing Lists", RFC 1211, March
  1008.                   1991.
  1009.       
  1010.       1327        Hardcastle-Kille, S., "Mapping between X.400(1988) /
  1011.                   ISO 10021 and RFC 822", RFC 1327, UCL, May 1992.
  1012.       
  1013.       1328        Hardcastle-Kille, S., "X.400 1988 to 1984
  1014.                   downgrading", RFC 1328, UCL, May 1992
  1015.       
  1016.       Concord     J. Houttuin, "Concord functional requirements",
  1017.                   COSINE MHS server, Mail: cosine-mhs-
  1018.                   server@nic.switch.ch, FTP: nic.switch.ch, Username:
  1019.                   cosine , File: procedures/echo-server-reqs
  1020.  
  1021. Houttuin                   Expires September 1993             [page 17]
  1022.  
  1023. Internet-Draft             MBS recommendations               March 1993
  1024.  
  1025.       
  1026.       Noreply     "list of surnames/usernames not to automatically
  1027.                   reply to", COSINE MHS server, Mail: cosine-mhs-
  1028.                   server@nic.switch.ch, FTP: nic.switch.ch, Username:
  1029.                   cosine , File: procedures/dontreply
  1030.       
  1031.       X.4xx(84)   CCITT Recommendations X.400 - X.430. Data
  1032.                   Communication Networks: Message Handling Systems.
  1033.                   CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga-
  1034.                   Torremolinos 1984
  1035.       
  1036.       X.4xx(88)   CCITT Recommendations X.400 - X.420. Data
  1037.                   Communication Networks: Message Handling Systems.
  1038.                   CCITT Blue Book, Vol. VIII - Fasc. VIII.7, Melbourne
  1039.                   1988
  1040.       
  1041.       SHK92       Hardcastle-Kille, S., "MHS use of the Directory to
  1042.                   support distribution lists", Internet-Draft draft-
  1043.                   ietf-mhsds-mhsuse-02.txt, November 1992
  1044.  
  1045.  
  1046. 8. Abbreviations
  1047.  
  1048.       ASCII    American Standard Code for Information Exchange
  1049.       CCITT    Comite Consultatif International de Telegraphique et
  1050.                Telephonique
  1051.       COSINE   Co-operation for OSI networking in Europe
  1052.       DL       Distribution List
  1053.       DM       Deliver Message
  1054.       EAN      MHS software (not an abbreviation)
  1055.       IPM      Inter-Personal Message
  1056.       IPN      Inter-Personal Notification
  1057.       ISO      International Organisation for Standardisation
  1058.       MHS      Message Handling System
  1059.       MBS      Mail based server
  1060.       MOTIS    Message-Oriented Text Interchange Systems
  1061.       MTA      Message Transfer Agent
  1062.       MTL      Message Transfer Layer
  1063.       MTS      Message Transfer System
  1064.       NJE      Network Job Entry
  1065.       NRN      Non-Receipt Notification
  1066.       PP       MHS software (not an abbreviation)
  1067.       RARE     Reseaux Associes pour la Recherche Europeenne
  1068.       RN       Receipt Notification
  1069.       SMTP     simple mail transfer protocol
  1070.       UA       User Agent
  1071.  
  1072.  
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078. Houttuin                   Expires September 1993             [page 18]
  1079.  
  1080. Internet-Draft             MBS recommendations               March 1993
  1081.  
  1082. 9. Author's Address
  1083.  
  1084.    
  1085.    Jeroen Houttuin
  1086.    
  1087.    RARE Secretariat
  1088.    Singel 466-468
  1089.    NL-1017 AW  Amsterdam
  1090.    Europe
  1091.    Tel +31 20 6391131
  1092.    Fax +31 20 6393289
  1093.    houttuin@rare.nl
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127.  
  1128.  
  1129.  
  1130.  
  1131.  
  1132.  
  1133.  
  1134.  
  1135. Houttuin                   Expires September 1993             [page 19]
  1136.